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Mapping and Interworking of Diversion Information between Diversion and 
History-Info Header Fields in the Session Initiation Protocol (SIP) 


Abstract 


Although the SIP History-Info header field described in RFC 7044 is 
the solution adopted in IETF, the non-standard Diversion header field 
described, as Historic, in RFC 5806 is nevertheless already 
implemented and used for conveying call-diversion-related information 
in Session Initiation Protocol (SIP) signaling. 


RFC 7044 obsoletes the original RFC 4244 and redefines the History- 
Info header field for capturing the history information in requests. 


Since the Diversion header field is used in existing network 
implementations for the transport of call diversion information, its 
interworking with the SIP History-Info standardized solution is 
needed. This document describes a recommended interworking guideline 
between the Diversion header field and the History-Info header field 
to handle call diversion information. This work is intended to 
enable the migration from non-standard implementations toward IETF 
specification-based implementations. 


This document obsoletes RFC 6044, which describes the interworking 
between the Diversion header field defined in RFC 5806 and the 
obsoleted History-Info header field defined on RFC 4244. 
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Status of This Memo 


This document is not an Internet Standards Track specification; it is 
published for informational purposes. 


This is a contribution to the RFC Series, independently of any other 
RFC stream. The RFC Editor has chosen to publish this document at 
its discretion and makes no statement about its value for 
implementation or deployment. Documents approved for publication by 
the RFC Editor are not a candidate for any level of Internet 
Standard; see Section 2 of RFC 5741. 


Information about the current status of this document, any errata, 
and how to provide feedback on it may be obtained at 
http://www.rfc-editor.org/info/rfc7544. 


Copyright Notice 


Copyright (c) 2015 IETF Trust and the persons identified as the 
document authors. All rights reserved. 


This document is subject to BCP 78 and the IETF Trust’s Legal 
Provisions Relating to IETF Documents 
(http://trustee.ietf.org/license-info) in effect on the date of 
publication of this document. Please review these documents 


carefully, as they describe your rights and restrictions with respect 
to this document. 
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1. Introduction 
1.1. Overview 


For some services based on VoIP (Voice over IP) services (e.g., 
voicemail, Interactive Voice Recognition (IVR), or automatic call 
distribution), it is helpful for the called SIP user agent to 
identify from whom and why the session was diverted. For this 
information to be used by various service providers or by 
applications, it needs to pass through the network. This is possible 
with two different SIP header fields: the History-Info header field 
defined in [RFC7044] and the historic Diversion header field defined 
in [RFC5806]. Both of these header fields are able to transport 
diversion information in SIP signaling. 


Although the Diversion header field is not standardized, it has been 
widely implemented. Therefore, it is useful to have guidelines to 
make this header field interwork with the standard History-Info 
header field. 


Note that new implementation and deployment of the Diversion header 
field are strongly discouraged. 


This document provides a mechanism for the translation of header 
field content between the Diversion header field and the History-Info 
header field. 


This document obsoletes [RFC6044]. 
1.2. Background 


The obsoleted History-Info header field [RFC4244] and its extension 
for forming SIP service URIs (including Voicemail URI) [RFC4458] used 
to be recommended by IETF to convey redirection information. They 
also used to be recommended in the Communication Diversion (CDIV) 
3GPP specification [TS_24.604]. 


The Diversion header field was originally described in a document 
that was submitted to the SIP Working Group and was eventually 
published as an Independent Submission as [RFC5806] for the 
historical record; it serves as a reference for this RFC. 


This header field contains a list of diverting URIs and associated 
information providing specific information as the reason for the call 
diversion. Most of the first SIP-based implementations have 
implemented the Diversion header field when no standard solution was 
ready to deploy. The IETF has standardized the History-Info header 
field partly because it can transport general history information. 
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This allows the receiving party to determine how and why the session 
is received. As the History-Info header field may contain further 
information than call diversion information, it is critical to avoid 
losing information and to be able to extract the relevant data using 
the retargeting cause URI parameter described in [RFC4458] for the 
transport of the call forwarding reason. 


The Diversion header field and the History-Info header field have 
different syntaxes, which are described in this document. Note that 
the main difference is that the History-Info header field is a 
chronological writing header whereas the Diversion header field 
applies a reverse chronology (i.e., the first diversion entry read 
corresponds to the last diverting user). 


Appendix A provides an interworking guideline between the Diversion 
header field and the Voicemail URI, which is another way to convey 
diversion information without using the History-Info header field. 
The Voicemail URI is defined in [RFC4458]. 

1.3. From RFC 4244 to RFC 7044 


The details of why and how [RFC4244] was obsoleted by [RFC7044] are 
provided in Section 16 of [RFC7044]. 


The main changes for implementation of the History-Info header field 
are as follows: 


1. The header field parameters "mp", "rc", and "np" were added to 
capture the specific method by which a target is determined. 


2. A way to indicate a gap in the History-Info header field was 
added by using a "0" in the index. 


3. To apply privacy, entries were anonymized rather than removed. 


4. Many SHOULDs were changed into MUSTs to have a more reliable 
header. 


Backward-compatibility aspects are discussed in Section 8 of this 
document. 


2. Problem Statement 
This section provides the baseline terminology used in the rest of 


the document and defines the scope of interworking between the 
Diversion header field and the History-Info header field. 
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There are many ways in which SIP signaling can be used to modify a 
session destination before it is established and many reasons for 
doing so. The behavior of the SIP entities that will have to further 
process the session downstream will sometimes vary depending on the 
reasons that led to changing the destination, for example, whether it 
is for a simple proxy to route the session or for an application 
server (AS) to provide a supplementary service. The Diversion header 
field and the History-Info header field differ in the approach and 
scope of addressing this problem. 


For clarity, the following vocabulary is used in this document: 


o Retarget/redirect: these terms refer to the process of a Proxy 
Server/User Agent Client (UAC) changing a Request-URI (Section 7.1 
of [RFC3261]) in a request and thus changing the target of the 
request. This includes changing the Request-URI due to a location 
service lookup and redirect processing. This also includes 
internal (to a proxy/SIP intermediary) changes of the URI prior to 
forwarding of the request. The term "retarget" is defined in 
[RFC7044]. 


o Call forwarding/call diversion/communication diversion: these 
terms are equivalent and refer to the Communications Diversion 
(CDIV) supplementary services, based on the ISDN Communication 
diversion supplementary services and defined in 3GPP [TS_24.604]. 
They are applicable to entities that are intended to modify the 
original destination of an IP multimedia session during or prior 
to the session establishment. 


This document does not intend to describe when or how History-Info or 
Diversion header fields should be used. Hereafter is provided 
clarification on the context in which the interworking is required. 


The Diversion header field has exactly the same scope as the call 
diversion service, and each header field entry reflects a call 
diversion invocation. The Diversion header field is used for 
recording call forwarding information that could be useful to network 
entities downstream. Today, this SIP header field is implemented by 
several manufacturers and deployed in networks. 


The History-Info header field is used to store all retargeting 
information, including call diversion information. As such, the 
History-Info header field [RFC7044] is used to convey Call-diversion- 
related information by using a cause URI parameter [RFC4458] in the 
relevant entry. 
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Note, however, that the use of cause URI parameter [RFC4458] ina 
History-Info entry for a call diversion is specific to the 3GPP 
specification [TS_24.604]. [RFC4458] focuses on retargeting toward a 
voicemail server and does not specify whether the cause URI parameter 
should be added in a URI for other cases. As a consequence, 
implementations that do not use the cause URI parameter for call 
forwarding information are not considered for the mapping described 
in this document. Nevertheless, some recommendations are given in 
the next sections on how to avoid the loss of non-mapped information 
at the boundary between a network region using the History-Info 
header field and one using the Diversion header field. 


[RFC7044] defines three header field parameters: "rc", "mp", and 
"np". The header field parameters "rc" and "mp" indicate the 
mechanism by which a new target for a request is determined. The 
header field "np" reflects that the target has not changed. All 
parameters contain an index whose value refers to the hi-index of the 
hi-entry, which contains a hi-targeted-to-uri that represents the 
Request-URI that was retargeted. 


Since both header fields address call forwarding needs, diverting 
information could be mixed up or be inconsistent if both are present 
in an uncoordinated fashion in the INVITE request. So, Diversion and 
History-Info header fields must not independently coexist in the same 
session signaling. This document addresses how to convert 
information between the Diversion header field and the History-Info 
header field and when and how to preserve both header fields to cover 
additional cases. 


For the transportation of consistent diversion information 
downstream, it is necessary to make the two header fields interwork. 
Interworking between the Diversion header field and the History-Info 
header field is introduced in Sections 5 and 6. Since the 
coexistence scenario may vary from one use Case to another, 
guidelines regarding interaction of header fields are proposed in 
Section 3. 


3. Interworking Recommendations 
3.1. General Recommendations 
Interworking function (IWF): 
In a normal case, the network topology assumption is that the 
interworking described in this document should be performed by a 
specific SIP border device that is aware, by configuration, that 


it is at the border between two regions, one using the History- 
Info header field and one using the Diversion header field. 
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As the History-Info header field is a standard solution, a network 
using the Diversion header field must be able to provide information 
to a network using the History-Info header field. In this case, to 
avoid coexistence of header fields, it is required to replace, as 
often as possible, the Diversion header field with the History-Info 
header field in the INVITE request during the interworking. 


Since, the History-Info header field has a wider scope than the 
Diversion header field, it may be used for needs and services other 
than call diversion. In addition, to trace call diversion 
information, the History-Info header field also acts as a session 
history and can store all successive Request-URI values. 
Consequently, even if it should be better to remove the History-Info 
header field after the creation of the Diversion header field to 
avoid confusion, the History-Info header field must remain unmodified 
in the SIP signaling if it contains supplementary (non-diversion) 
information. It is possible to have History-Info header fields that 
do not have values that can be mapped into the Diversion header 
field. In this case, no interworking with the Diversion header field 
should be performed, and it must be defined per implementation what 
to do in this case. This point is out of the scope of this document. 


In conclusion, it is recommended to have local policies minimizing 
the loss of information and find the best way to keep it up to the 
terminating user agent. 


The following sections describe the basic use cases. Additional 
interworking cases are described in Section 7.4. 


3.2. Privacy Considerations 


When a SIP message is forwarded to a domain for which the SIP 
intermediary is not responsible, a Privacy Service at the boundary of 
the domain applies the appropriate privacy based on the value of the 
Privacy header field in the message header or in the privacy 
parameter within the concerned header: 


1. For the History-Info header field, it is the Privacy header field 
included as the "headers" component of the hi-targeted-to-uri in 


the individual hi-entries with the priv-value "history". 


2. For the Diversion header field, it is the diversion-privacy 
parameter "privacy" in each Diversion header field. 
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For the History-Info header field, as recommended in [RFC7044]: 


o If there is a Privacy header field in the message header of a 
request with a priv-value of "header" or "history", then all the 
hi-targeted-to-uris (in the hi-entries associated with the domain 
for which the SIP intermediary is responsible) are anonymized by 
the Privacy Service. The Privacy Service must change any 
hi-targeted-to-uri in these hi-entries that have not been 
anonymized to the anonymous SIP URI "anonymous@anonymous.invalid" 
as recommended in Sections 4.1.1.2 and 4.1.1.3 of [RFC3323]. 


o If there is a Privacy header field in the "headers" component of a 
hi-targeted-to-uri with a priv-value of "history", then all the 
concerned hi-entries must be anonymized as described above prior 
to forwarding. 


The Privacy Service must remove the Privacy header field from the 
"headers" component of the hi-targeted-to-uris of the concerned 
hi-entries and the priv-value of "history" from the Privacy header 
field in the message header of the request prior to forwarding. If 
there are no remaining priv-values in the Privacy header field, the 
Privacy Service must remove the Privacy header field from the 
request. 


For the Diversion header field: 


o If there is a Privacy header field in the message header of a 
request with a priv-value of "header", then all the addresses in 
the Diversion header fields (associated with the domain for which 
the SIP intermediary is responsible) are anonymized by the Privacy 
Service by changing the address to the anonymous SIP URI 
"anonymous@anonymous.invalid" as recommended in Sections 4.1.1.2 
and 4.1.1.3 of [RFC3323] prior to forwarding. 


o For each Diversion header field or each entry in the Diversion 
header field, if there is a diversion-privacy parameter with a 
value set to "full", "uri", or "name", then the concerned 
Diversion header field address must be anonymized as described 
above prior to forwarding. 


In the concerned Diversion header field entries, the diversion- 
privacy parameter must be removed from the header. 


The privacy information interworking as described in Sections 5 and 6 


must only be considered within a trusted domain that ensures correct 
application of the privacy requirements. 
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3.3. Headers in SIP Method 


The recommended interworking presented in this document should apply 
only for INVITE requests. 


In 3xx responses: 


Both History-Info and Diversion header fields could be present in 
3xx responses. 


When a proxy wants to interwork with a network supporting the 
other header field, it should apply the interworking between 
Diversion header field and History-Info header field in the 3xx 
response. 


When a recursing proxy redirects an initial INVITE after receiving 
a 3xx response, it should add as a last entry either a Diversion 
header field or a History-Info header field (according to its 
capabilities) in the forwarded INVITE. Local policies could apply 
regarding whether or not to send the received header field in the 
next INVITE. 


In SIP responses other than 100: 


All SIP responses where the History-Info header field could be 
present are not used for the call forwarding service and should 
not be changed into the Diversion header field. The destination 
network must be transparent to the received History-Info header 
field. 


Note: The following mapping is inspired by the ISDN User Part (ISUP) 
to SIP interworking described in [TS_29.163]. 


3.4. SIP Network/Terminal Using Diversion Header Field to SIP Network/ 
Terminal Using History-Info Header Field 


When the Diversion header field is used to create a History-Info 
header field, the Diversion header field must be removed in the 


outgoing INVITE. It is assumed that all the information present in 
the Diversion header field is transferred in the History-Info header 
field. 


If a History-Info header field is also present in the incoming INVITE 
(in addition to the Diversion header field), the Diversion header 
field and History-Info header field present must be mixed, and only 
the diversion information not yet present in the History-Info header 
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field must be inserted as a last entry (most recent) in the existing 
History-Info header field, following the creation process recommended 
in [RFC7044]. 


As an example, this could be the case of an INVITE coming from 
network_2 using the Diversion header field but previously passed 
through network_1 using the History-Info header field (or the 
network_2 uses History-Info header field to transport successive URI 
information) and going to network_3 using the History-Info header 
field. 


IWF* IWF* 
network_1 | network_2 |network_3 
History-Info | Diversion [using 
| |History- 
Info 
UA A P1 AS B | P2 AS C UA C AS D UA E 
| | | | | | | | | | 
| INVITE | | | | | | | | | 
¡== > | | | | | | | | | 
| | | | | | | | | | 
INVITE 

fee ee ee ee 
| | Supported: histinfo | | | | | | 
| History-Info: | | | | | | 
| | <sip:proxyP1>;index=1, | | | | | | 

| | <sip:userB>; index=1.1;rc=1 | | | | 
P| fm | O ee 
| | |------ >| | | o | | 
| | |History-Info: | | | | | | 
| | |<sip:proxyP1>; index=1, | | | | | 
| | |<sip:userB>; index=1.1;rc=1, | | | | 

| | |<sip:userC; cause=302>; index=1.1.1;mp=1.1 | 


In this case, the incoming INVITE contains a Diversion header field 
and a History-Info header field. Therefore, as recommended in this 
document, it is necessary to create, for network_3, a single History- 
Info header field gathering existing information from both the 
History-Info and the Diversion header fields received. Anyway, it is 
required that network_2 (i.e., IWF) remove the Diversion header field 
when the message is going to a network not using the Diversion header 
field. Then, network_3 could use call forwarding information that is 
present in a single header field and add its own diversion 
information if necessary. 
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Notes: 


1. If a network is not able either to use only one header field each 
time or to maintain both header fields up to date, the 
chronological order cannot be certified. 


2. It is not possible to have only a Diversion header field when the 
History-Info header field contains more than call diversion 
information. If previous policy recommendations are applied, the 
chronological order is respected as Diversion entries are 
inserted at the end of the History-Info header field taking into 
account the Diversion internal chronology. 


3.5. SIP Network/Terminal Using History-Info Header Field to SIP 
Network/Terminal Using Diversion Header Field 


When the History-Info header field is interpreted to create a 
Diversion header field, some precautions must be taken. 


If the History-Info header field contains only call forwarding 
information, then it must be deleted after the interworking. 


If the History-Info header field contains other information, then 
only the information of concern to the diverting user must be used to 
create entries in the Diversion header field, and the History-Info 
header field must be kept as received in the INVITE and forwarded 
downstream. 


Note: The History-Info header field could be used for reasons other 
than call diversion services, for example, by a service that needs to 
know if a specific AS has yet been invoked in the signaling path. If 
the call is later forwarded to a network using the History-Info 
header field, it would be better not to lose history information due 
to passing though the network that only supports the Diversion header 
field. A recommended solution must not disrupt the standard 
behavior, and networks that do not implement the History-Info header 
field must be transparent to a received History-Info header field. 


If a Diversion header field is present in the incoming INVITE (in 
addition to the History-Info header field), only diversion 
information present in the History-Info header field but not in the 
Diversion header field must be inserted from the last entry (most 
recent) into the existing Diversion header field as recommended in 
[RFC5806]. 


Note that the chronological order could not be certified. If 


previous policy recommendations are respected, this case should not 
happen. 
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Forking case: 


The History-Info header field enables the recording of sequential 
forking for the same served user. During an interworking from the 
History-Info header field to the Diversion header field, the 
History-Info entries containing a forking situation (with an 
incremented "index" parameter) could possibly be mapped if they 
contain a call forwarding "cause" parameter. The interworking 
entity could choose to create only a Diversion entry or not apply 
the interworking. The choice could be done according a local 
policy. 


The same logic is applied for an interworking with Voicemail URI (see 
Appendix A). 


4. Reminder of the Syntax for Header Fields 
4.1. History-Info Header Field Syntax 


The ABNF syntax [RFC5234] for the History-Info header field and 
header field parameters is as follows. 


History-Info = "History-Info" HCOLON hi-entry *(COMMA hi-entry) 
hi-entry = hi-targeted-to-uri *(SEMI hi-param) 
hi-targeted-to-uri = name-addr 

hi-param = hi-index/hi-target-param/hi-extension 
hi-index = "index" EQUAL index-val 

index-val = number *("." number) 

number = [ $x31-39 *DIGIT ] DIGIT 
hi-target-param = rc-param / mp-param / np-param 
rc-param = "rc" EQUAL index-val 

mp-param = "mp" EQUAL index-val 

np-param = "np" EQUAL index-val 

hi-extension = generic-param 


The ABNF definitions for "generic-param", "name-addr", "HCOLON", 
"COMMA", "SEMI", and "EQUAL" are from [RFC3261]. 


The History-Info header field is specified in [RFC7044]. The top- 


most History-Info entry (first in the list) corresponds to the oldest 
history information. 
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Cause URI parameter: 


A hi-entry may contain a cause URI parameter expressing the 
diversion reason. This cause URI parameter is defined in 
[RFC4458]. The ABNF grammar [RFC5234] for the cause-param 
parameter is shown below as it has been subject to Erratum ID 1409 
[Err1409] for [RFC4458]. The Status-Code is defined in [RFC3261]. 


cause-param = "cause=" Status-Code 


The cause-param parameter is a SIP/SIPS URI parameter and should 
be inserted in the History-Info entry (URI) of the diverted-to 
user in case of call diversion as recommended in the 3GPP CDIV 
specification [TS_24.604]. The cause values used in the cause- 
param for the diverting reason are listed in [RFC4458]. Because 
it is a parameter dedicated to call forwarding service, its 
presence is used to determine that a hi-entry is a diverting user. 
More precisely, each diverting user is located in the hi-entry 
before the one containing a cause-param with cause value as listed 
in [RFC4458]. 


Reason header field: 


The Reason header field defined in [RFC3326] should be escaped in 
the hi-entry of the diverting user when the call diversion is due 
to a received SIP response. The Reason header field contains a 
cause parameter set to the true SIP response code received 
(Status-Code). 


Therefore, in case of call diversion due to a SIP response, both 
cause parameters should be used. The complexity is that these 
parameters could be used at the same time in the History-Info 
header field but not in the same hi-entry and not with the same 
meaning. Only the cause-param is dedicated to call diversion 
service. The ’cause’ Reason header field parameter is not taken 
into account in the mapping with a Diversion header field. 


Target URI parameter: 


[RFC4458] also defines the 'target” URI parameter, which could be 
inserted in a Request-URI and consequently in the 
hi-targeted-to-uri. This parameter is used to keep the diverting 
user address in the downstream INVITE request in Voicemail URI 
implementation. As this information is already present in the hi- 
entries, the 'target” URI parameter is not taken into account 
regarding the interworking with the Diversion header field. From 
the Diversion header field, it could be possible to create the 
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‘target’ URI parameter in the hi-entries and/or in the Request- 
URI, but this possibility is based on local policies not described 
in this document. 


Privacy header field: 
A Privacy header field as defined in [RFC3323] could also be 
embedded in hi-entries with the 'history” value defined in 
[RFC7044]. 


Index header field parameter: 


The index parameter is a string of digits, separated by dots, to 
indicate the number of forward hops and retargets. 


Note: A history entry could contain the "gr" parameter. Regardless 
of the rules concerning the "gr" parameter defined in [TS_24.604], 

which must be applied, this parameter has no impact on the mapping 

and must only be copied with the served user address. 


Missing entry: 


If the request clearly has a gap in the hi-entry (i.e., the last 
hi-entry and Request-URI differ), the entity adding a hi-entry 


must add a single index with a value of "0" (i.e., the non- 
negative integer zero) prior to adding the appropriate index for 
the action to be taken (e.g., Index=1.1.2.0.1). Prior to any 


application usage of the History-Info header field parameters, the 
SIP entity that processes the hi-entries must evaluate the 
hi-entries and determine if there are any gaps in them. 


"histinfo" option tag: 


According to [RFC7044], a proxy that receives a Request with the 
"histinfo" option tag in the Supported header field should return 
captured History-Info in subsequent, provisional, and final 
responses to the Request. The behavior depends upon whether or 
not the local policy supports the capture of History-Info. 


Example: 


History-Info: 
<sip:diverting_userl_addr?Privacy=none&Reason=SIP%3Bcause%3D302>; 
index=1, 

<sip:diverting_user2_addr; cause=480?Privacy=history>; index=1.1;mp=1, 
<sip:last_diversion_target; cause=486>; index=1.1.1;mp=1.1 
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4.2. Diversion Header Field Syntax 


The following text is restating the exact syntax that the production 
rules in [RFC5806] define, but using ABNF [RFC5234]: 


Diversion = "Diversion" HCOLON diversion-params 
* (COMMA diversion-params) 
diversion-params = name-addr *(SEMI (diversion-reason / 


diversion-counter / diversion-limit / 
diversion-privacy / diversion-screen / 
diversion-extension)) 

diversion-reason = "reason" EQUAL ("unknown" / "user-busy" / 
"no-answer" / "unavailable" / "unconditional" 
/ "time-of-day" / "do-not-disturb" / 
"deflection" / "follow-me" / "out-of-service" 
/ "away" / token / quoted-string) 


diversion-counter = "counter" EQUAL 1*2DIGIT 

diversion-limit = "limit" EQUAL 1*2DIGIT 

diversion-privacy = "privacy" EQUAL ("full" / "name" / "uri" / 
"off" / token / quoted-string) 

diversion-screen = "screen" EQUAL ("yes" / "no" / token / 


quoted-string) 
diversion-extension = token [EQUAL (token / quoted-string) ] 


Note: The Diversion header field could be used in the comma-separated 


format as described below and in a header-separated format. Both 
formats could be combined in a received INVITE as recommended in 
[RFC3261]. 

Example: 

Diversion: 


<sip:diverting_user2_addr>; reason=user-—busy; counter=1;privacy=full, 
<sip:diverting_userl_addr>; reason=unconditional; counter=1; privacy=off 


5. Diversion Header Field to History-Info Header Field 


The following text is valid only if no History-Info header field is 
present in the INVITE request. If at least one History-Info header 
field is present, the interworking function must adapt its behavior 
to respect the chronological order. For more information, see 
Section 3. 


Concerning the privacy information in the Diversion header field, the 


following mapping only applies within a trusted domain; for other 
domains, see the privacy considerations in Section 3.2. 
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For N Diversion entries, N+1 History-Info entries must be created. 
To create the History-Info entries in the same order as during a 
session establishment, the Diversion entries must be mapped from the 
bottom-most to the top-most. Each Diversion entry shall be mapped 
into a History-Info entry. An additional History-Info entry (the 
last one) must be created with the diverted-to party address present 
in the Request-URI of the received INVITE. The mapping is described 
in the table below. 


The first entry created in the History-Info header field contains: 


o a hi-targeted-to-uri with the name-addr parameter of the bottom- 
most Diversion header field. 


o if a privacy parameter is present in the bottom-most Diversion 
entry, then a Privacy header field must be escaped in the History- 
Info header field as described in the table below. 


o a hi-index set to 1. 


For each of the following Diversion entries (from bottom to top), the 
History-Info entries are created as follows (from top to bottom): 


Source Destination 

Diversion header component: History-Info header component: 
name-addr hi-targeted-to-uri 

reason of the previous cause URI parameter 

Diversion entry A cause-param "cause" is 


added in each hi-entry 
(except the first one) 


"UNKNOWRS == RARA AROS ee 404 (default 'cause' value) 
"unconditional"--------~-------------------- 302 
"“user=búsy"======5+22=2= 2529922 = 1929-2237 486 
"no>answer"=========+==5=++52+==9 === 408 
"deflection === HS 33255 480 or 487 
"unavailable" --=-=-========= === 503 
“time=of-day"=======5=2====2====2==+SH= == 404 (default) 
"do-nt disturb = A tnn A 228225222 404 (default) 
"follow=me"============2==12=====H52s======= 404 (default) 
"OUt=Ot=Ser vice) === 722 == SST SS AOS e 404 (default) 
"away ===S===5====9+9==535S8=5====9SSs===%s 404 (default) 
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counter hi-index 

"1" or parameter === === The previous created index 

not present is extended with ".1" 

Superior Co TIT ===========2=5=22552+====3= Create N-1 placeholder History 
(i.e., N) entry with the previous index 


extended with ".1" 

Then the History-Info header 
created with the Diversion 
entry with the previous index 
extended with ".1" 


privacy Privacy header escaped in the 
hi-targeted-to-uri 

tul li==========+==2>===+225292=ps=55=>=s2 "history" 

TOFT 322 IRE SRA AEREA Privacy header field 
absent or "none" 

MNAMe™ HHS SHS SSS a E A "history" 

a Se SaaS a SaaS a ee a eae "history" 


hi-target-param 

An mp-param "mp" is added in 
each created hi-entry 
(except the first one) 

The "mp" parameter is set to 
the index value of the 
preceding hi-entry. 


A last History-Info entry is created and contains: 
o a hi-targeted-to-uri with the Request-URI of the INVITE request. 


o a cause-param from the top-most Diversion entry, mapped from the 
diversion-reason as described above. 


o an index set to the previous created index extended with a new 
level ".1" added at the end. 


o a hi-target-param set to "mp" equals to the index value of the 
previous hi-entry. 


Notes: 
1. For other optional Diversion parameters, there is no 


recommendation as the History-Info header field does not provide 
equivalent parameters. 
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2. For values of the diversion-reason that are mapped with a 
recommended default value, it could also be possible to choose 
another value. The cause-param URI parameter offers fewer 
possible values than the diversion-reason parameter. However, it 
has been considered that the cause-param values list was 
sufficient to implement CDIV service as defined in 3GPP 
[TS_24.604] as it covers a large portion of cases. 


3. The Diversion header field can contain a "tel" URI as defined in 
[RFC3966] in the name-addr parameter. The History-Info header 
field can also contain an address that is a "tel" URI, but if 
this hi-entry has to be completed with either a SIP header field 
(e.g., Reason or Privacy) or a SIP URI parameter (e.g., 'cause” 
or 'target'), the "tel" URI must be converted into a SIP URI. 
[RFC3261] gives an indication as to the mapping between sip: and 
tel: URIs, but in this particular case, it is difficult to assign 
a valid hostport as the diversion occurred in a previous network 
and a valid hostport is difficult to determine. So, it is 
suggested that in case of "tel" URI in the Diversion header 
field, the History-Info header field should be created with a SIP 
URI with user=phone and a domain set to "unknown.invalid". 


4. The Diversion header field allows carrying of a counter that 
retains the information about the number of successive 
redirections. History-Info does not have an equivalent because 
to trace and count the number of diversions, it is necessary to 
count the cause parameter containing a value associated to a call 
diversion listed in [RFC4458]. Reading the index value is not 
enough. With the use of the "placeholder" entry the History-Info 
header field, entries can reflect the real number of diversions 
that occurred, thanks to the cause-param. 


Example of placeholder entry in the History-Info header field: 
<sip:unknown@unknown. invalid; cause=xxx>; index=1.1 
<sip:bob_addr; cause=404>; index=1.1.1;mp=1.1 

"Ccause=xxx" reflects the diverting reason of a previous diverting 

user. For a placeholder hi-entry, the value "404" must be taken for 


the cause-param and so, located in the next hi-entry. 


For recommendations for local policies regarding the coexistence of 
header fields in the INVITE request, see Sections 3 and 7.4. 
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6. History-Info Header Field to Diversion Header Field 


Concerning the privacy information for the History-Info header field, 
the following mapping only applies within a trusted domain; for other 
domains, see the privacy considerations in Section 3.2. 


To create the Diversion entries in the same order as during a session 
establishment, the History-Info entries must be mapped from the top- 
most to the bottom-most. The first History-Info header field entry 
selected will be mapped into the last Diversion header field entry 
and so on. One Diversion header field entry must be created for each 
History-Info entry that has cause-param with a value listed in 
[RFC4458]. 


Diversion information: 


The definitions of "Target_entry" and "Diverting_entry" are included 
below to help readers understand the mapping of the History-Info 
header field. 


The diversion information can be identified by finding the following 
hi-entries: 


o Target_entry: hi-entries containing a cause-param URI parameter 
with a value listed in [RFC4458] will contain the diversion reason 
and the address of the target of the concerned call forwarding. 
Per [RFC7044], these hi-entries may also contain a hi-target-param 
set to "mp". 


o Diverting_entry: For each previously identified hi-entry: 


* If there is an "mp" header field parameter, the hi-entry whose 
hi-index matches the value of the hi-target-param "mp" will 
contain the diverting party address, its possible privacy, and/ 
or SIP reason when the retargeting has been caused by a 
received SIP response. 


* If there is no "mp" header field parameter, the information of 
the diverting party address, privacy and/or SIP reason will be 
found in the hi-entry that precede this identified hi-entry. 


Note: Per [RFC7044], all retargeting entries must point to a hi-entry 
that contains an "mp" parameter, but for backward-compatibility 
reasons, it may be absent from some of the received hi-entries. See 
Section 8 for more information on backward compatibility. 


The History-Info header field must be mapped into the Diversion 
header field as follows: 


Mohali Informational [Page 20] 


RFC 7544 Mapping of Diversion and History-Info August 2015 


Source Destination 
History-Info header component: Diversion header component: 
hi-targeted-to-uri name-addr 


of the Diverting_entry. 


cause-param reason 
of the Target_entry 

ADA O O O a a a S "unknown" (default value) 
A ea a eee aS "unconditional" 

AQ OAS SsnR ssh sane eS Ss sn ase a ase "user-busy" 
a a SS aa "no-answer" 

480 or 487----------~---------------------- "deflection " 
SUITES ROA "unavailable" 

hi-index counter 

Mandatory parameter :¡[or===============++H== The counter is set to "1". 


History-Info reflecting 
the chronological order 
of the information. 


Privacy header field escaped privacy 
in the hi-targeted-to-uri 

of the Diverting_entry 

"history -s<-Ss sss - sss ees sees a 9 =-=e2= “full” 
Privacy header field ---------------------- "off" 
Absent or "none" 


Note: For other optional History-Info parameters, there is no 
recommendation as the Diversion header field does not provide 
equivalent parameters. 


For recommendations for local policies regarding the coexistence of 
header fields in the INVITE request, see Section 3. 
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7. Examples 


7.1. Example with Diversion Header Field Changed into History-Info 
Header Field 


INVITE sip:last_diverting_target 

Diversion: 

<sip:diverting_user3_address>; reason=unconditional;counter=1; 
privacy=off, 

<sip:diverting_user2_address>; reason=user-—busy; counter=1; 
privacy=full, 

<sip:diverting_userl_address>; reason=no-answer; counter=1; 
privacy=off 


Mapped into: 


History-Info: 
<sip:diverting_userl_address?Privacy=none>; index=1, 
<sip:diverting_user2_address; 

cause=408?Privacy=history>; index=1.1;mp=1, 
<sip:diverting_user3_address; 

cause=486?Privacy=none>; index=1.1.1;mp=1.1, 
<sip:last_diverting_target; cause=302>; index=1.1.1.1;mp=1.1.1 


7.2. Example with History-Info Header Field Changed into Diversion 
Header Field 


INVITE sip:last_diverting_target; cause=486 

History-Info: 

<sip:diverting_userl_address?Privacy=history>; index=1, 
<sip:diverting_user2_address; cause=302?Privacy=none>; index=1.1;mp=1, 
<sip:last_diverting_target; cause=486>; index=1.1.1;mp=1.1 


Mapped into: 


Diversion: 
<sip:diverting_user2_address>; reason=user-—busy; counter=1; privacy=off, 
<sip:diverting_userl_address>; reason=unconditional; counter=1; privacy= 
full 


7.3. Example with Two SIP Networks Using History-Info Header Field 
Interworking with a SIP Network Using Diversion Header Field 


A -> Pl -> B -> C -> P2 -> D-> E 

A, B, C, D and E are users. 

B, C and D have call forwarding service invoked. 

P1 and P2 are proxies. 

Only relevant information is shown on the following call flow. 
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IWF* IWF* 
SIP network using | SIP network using | SIP net. 
History-Info Diversion lusing 


History-Info 


2 AS C UA C AS D UA 


| Supported: histinfo 
| History-Info: 
| <sip:proxyP1>; index=1, 
<sip:userB>; index=1.1;rc=1 


P 
| 
| 
| 
| 
| 


[INV c | | 


|History-Info: | 
<sip:proxyP1>; index=1, 
<sip:userB>; index=1.1;rc=1, 
in app eee 
| [anv c | | | 
| |----->| | ; | 
| Diversion: | | | | | 
<sip:userB>; reason=unconditional;counter=1; Ema off 
[nistor Info: | | | 
<sip:proxyP1>; index=1, | | | 
<sip:userB>;index=1.1;rc=1, | 
i proxyP2; cause=302>; index=1.1.1;mp=1.1 


| | 
No modification of Diversion header 
| | 
| 
| 
| No response timer expires 
| | | |---1nv D --->| 
|Diversion: | 
<sip:userC>; reason=no-answer;counter=1;privacy=full, 


<sip:userB>; reason=unconditional;counter=1;privacy=off 
| History-Info: | 


S A 
| | 
| | 
| | 
| | 
| | 
| | 
| | 
| | 
| | 
| 


| 
| | 
o 
| | 
| | 
| | 
| | 
o 
| | 
| | 
| | 
| | 
TS 
Pp 
| 
| 
| 


| 
| 
eel) itl 
| 
| 
| 


E 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
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| <sip:proxyP1>; index=1, | | 

| <sip:userB>; index=1.1;rc=1, | | 

| <sip:proxyP2; cause=302>; index=1.1.1;mp=1.1 
| 

| | 
| 


| | 
| | | | | | INV E | 
| | | | | | ae | 
| |Diversion: | | 
| <sip:userD>; reason=time-of-day;counter=1;privacy=off, | 
| <sip:userC>; reason=no-answer; counter=1;privacy=full, 
<sip:userB>; reason=unconditional; counter=1;privacy=off 
| | History-Info: | 
| | <sip:proxyP1>; index=1, | | 
| | <sip:userB>; index=1.1;rc=1, | | 
| | <sip:proxyP2; cause=302>; index=1.1.1;mp=1.1 | 
| 
| 
| 
| 
| 


| | | | | | 
INV E 
ee ee | ee 
| | | | 
| | | 
| 


History-Info: 
<sip:proxyP1>;index=1, 
<sip:userB>; index=1.1;rc=1, | 


<sip:proxyP2; cause=302>; index=1.1.1;mp=1.1, 
| <sip:userC ?Privacy=history>;index=1.1.1.0.1, 
<sip:userD; cause=408?Privacy=none>; index=1.1.1.0.1.1;mp=1.1.1.0.1, 


|<sip:userE; cause=404>; index=1.1.1.0.1.1.1;mp=1.1.1.0.1.1 


Note: The IWF is an interworking function that could be a stand-alone 
equipment not defined in this document (it could be a proxy). 


7.4. Additional Interworking Cases 


Even for particular cases in which both header fields could coexist, 
it should be the responsibility of the network local policy to make 
it work together. This section describes some situations and some 
recommendations on behavior. 


In the case where there is one network that includes different nodes, 
some of them supporting the Diversion header field and other ones 
supporting the History-Info header field, there is a problem when any 
node handling a message does not know the next node that will handle 
the message. This case can occur when the network has new and old 
nodes, the older ones using the Diversion header field and the most 
recent using the History-Info header field. 


While a network replacement may be occurring, there will be a time 


when both nodes coexist in the network. If the different nodes are 
being used to support different subscriber types due to different 
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node capabilities, then the problem is more important. In this case, 
there is a need to pass both the History-Info header field and the 
Diversion header field within the core network. 


These header fields need to be equivalent to ensure that, whatever 
the node receiving the message, the correct diversion information is 
received. This requires that, whatever the received header field, 
there is a requirement to be able to compare the header fields and to 
convert the header fields. Depending upon the node capability, it 
may be possible to make assumptions as to how this is handled. 


o If it is known that the older Diversion header field supporting 
nodes does not pass on any received History-Info header field, 


then the interworking becomes easier. If a message is received 
with only Diversion header fields, then it has originated from an 
old node. The equivalent History-Info entries can be created, and 


these can then be passed as well as the Diversion header field. 


o If the node creates a new History-Info header field for a call 
diversion, then an additional Diversion header field must be 
created. 


o If the next node is an old node, then the Diversion header field 
will be used by that node, and the History-Info entries will be 
removed from the message when it is passed on. 


o If the next node is a new node, then the presence of both the 
Diversion header field and History-Info header field means that 
interworking has already occurred and the Diversion and History- 
Info entries must be considered equivalent. 


o If both nodes pass on both the History-Info header field and 
Diversion header field but only actively use one, then both types 
of nodes need to perform the interworking and must maintain 
equivalence between the header fields. This will eventually 
result in the use of the Diversion header field being deprecated 
when all nodes in the network support the History-Info header 
field. 


o If a gap is identified in the History-Info header field by a node 
that would create a new entry, it shall add a single index with a 
value of "0" prior to adding the appropriate index for the action 
to be taken. 
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8. Backward Compatibility 


Issues with backward compatibility are due to the evolution of the 
History-Info header field from [RFC4244] to [RFC7044], as described 
in Section 1.3 of this document. Backward compatibility is taken 
into account throughout this document for the interworking with the 
Diversion header field. More details are provided in the "Backwards 
Compatibility" section of [RFC7044]. 


9. Security Considerations 
The security considerations in [RFC7044] and [RFC5806] apply. 
The privacy considerations described in Section 3.2 apply. 


The use of the Diversion header field or History-Info header field 
requires application of the requested privacy and integrity requested 
by each diverting user or entity. Without integrity, the requested 
privacy functions could be downgraded or eliminated, potentially 
exposing identity information. Without confidentiality, 
eavesdroppers on the network (or any intermediaries between the user 
and the Privacy Service) could see the very personal information that 
the user has asked the Privacy Service to obscure. Unauthorized 
insertion and deletion/modification of those header fields can 
provide misleading information to users and applications. A SIP 
entity that can provide a redirection reason in a History-Info header 
field or Diversion header field should be able to suppress this in 
accordance with privacy requirements of the user concerned. 
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Appendix A. Interworking between Diversion Header Field and Voicemail 
URI 


Voicemail URI is a mechanism described in [RFC4458] to provide a 
simple way to transport only one redirecting user address and the 
reason why the diversion occurred in the Request-URI of the INVITE 


request. This mechanism is mainly used for call diversion to a 
voicemail. 

A.l. Diversion Header Field to Voicemail URI 
Received: 


Diversion: userA-address; reason=user-—busy; counter=1; privacy=full 


Sent (Voicemail URI created in the R-URI line of the INVITE): 
sip: voicemail@example.com;target=userA-address; cause=486 SIP/2.0 


Mapping of the Redirection Reason is the same as for History-Info 
header field with a default value set to 404. 


If the Diversion header field contains more than one Diversion entry, 
the choice of the redirecting user information inserted in the URI is 
in charge of the network local policy. For example, the choice 
criterion of the redirecting information inserted in the URI could be 
the destination of forwarded INVITE request (whether or note the 
voicemail serves this user). 


Note: This interworking could be done in addition to the interworking 
of the Diversion header field into the History-Info header field. 


A.2. Voicemail URI to Diversion Header Field 


In case of real voicemail, this way of interworking should not 
happen. However, if for any reason it occurs, it is recommended to 
do it as follows: 


Received: 

INVITE sip: voicemail@example.com; \ 
target=sip:+33145454500%40example.com;user=phone; \ 
cause=302 SIP/2.0 


Sent in the forwarded INVITE: 
Diversion: sip:+33145454500%40example.com; user=phone; 
reason=unconditional; counter=1 
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